GPS: NASA Clipper

NASA Clipper users read these links.

NASA GPS Clipper Manuals is a broad and unique product to show current Speed over Ground (SOG), true bearing, distance to waypoint and bearing to waypoint in the cockpit. It does not use much power, is readable also at sunshine (what most colorful displays of PCs don’t) and it provides the most important information where to steer and distance to waypoint. However to set it up is very tricky and many threads in the various blogs tell of desperate user, who failed. I stumbled into the same. I wanted to use opencpn as a tool to provide me the required information as course to steer, distance to waypoint and current speed at the GPS repeater. Because the GPS repeater was already there and the PC display is in sun not readable and needs a lot of protection against water. My plan is to pack the PC safely under deck also for lousy rains or very windy weather and wire it to the GPS repeater. After many trials I found out it to be working. Several times I was ready to replace my repeater with another brand, but the NASA clipper GPS repeater is unique and I found no other one. In the end I solved the problem, but it requires

  1. Proper setting at the opencpn program (connection properties, filter of sentences and proper set flags
  2. Hardware like an Arduino or Rhasperry as a postprocessor converting the data received from opencpn program into correct data (because opencpn has many flaws concerning the NMEA output). Just taking an USB-RS232 converter won’t help.
  3. Hardware to convert that signal into RS232 code
  4. Hardware (Load resistor) to set up proper RS232 communication between postprocessor and GPS repeater

Important: All this applies to opencpn version 4.8.4 and 4.8.6 as i have seen the last update changes. Future updates in the software might have changed the whole topic, so please check the change-log of the opencpn versions, if the issues there have been adressed.

GPS repeater - connection properties

The NASA GPS repeater is a nice tool. It has 1 cable containing 2 wires and the shielding with:

  1. red: +12 V
  2. blue: NMEA input
  3. Shielding: Ground to overall power supply

Having only 1 NMEA cable means: It can only receive and the NMEA protocol is RS232. NMEA units with 2 cables for receiving have one for + and one for -. !! The minus is NOT Ground, it is - . If you connect it to Ground, you have solved your problem by sending your NMEA devices into the hunting grounds, aka killed it. The +/- means more important for us that this unit is requesting the signals in RS485 or RS422 (is the same) format. It has not only different voltages than RS232, also the flanks between 0 and 1 produce a different signal. So when you hook up a RS232 NMEA receiver to a RS485 sender, you’ll get nonsense on your display (what I did). Summarized, we need the signal as RS232, what meant that I cannot use my NMEA multiplexer Shipmodul lite, delivering RS422 signals. If you have a NMEA with a configurable output, set it to RS232. However unless the opencpn programmers have not corrected the flaws described here, it won’t help you either. The hand-shake between multiplexer and opencpn does not work in the current opencpn version 4.8.4. The Multiplexer has to process a lot of data. When it receives data from the PC and its reading-buffer is full, it sends a signal to the PC asking to stop sending further data, until its reading buffer is empty and could receive and process again data form the PC. Although many Multiplexers can do that, opencpn does not listen nor react. Opencpn in the current version (4.8.4) does not care about any buffer and keeps on sending. As a result the multiplexer can not store all the data sent, leading to corrupt the data in the buffer and garbage sent to the GPS repeater. Who in the end refuses to show anything and to display („No GPS SOG“).

The first step at the programmers of opencpn would be to update the handshake (hardware Flow Control) It would be important to do so, because it applies not only to GPS repeaters, but to every NMEA receiver (Autopilot etc.) With the road from opencpn via NMEA multiplexer to GPS repeater closed, I went to direct access i.e. USB from PC out to RS232 to GPS. Bought a standard USB to RS232 adapter, installed it, made the settings at opencpn - and failed with Hurray. GPS repeater laughing at me („No GPS signal and No GPS SOG“). Now I took it personally and dwelled deeper.

Postprocessor (Arduino) to PC connection

I used an Arduino (can be also a Rhasperry or anything else. The only reason, I am accustomed to Arduino) and connected it to the computer’s USB . Then i read out all the signals the PC with opencpn was sending. The Arduino board comes with an USB interface and does all the handshake and reading buffer things, so I had not anymore to fiddle with the tricky reading buffers. First I had to set the proper communication settings:

Do not forget to connect a GPS device to deliver GPS data. Else it won’t work either - nothing out from GPS - nothing in at GPS repeater. Now after having connected my terminal program showed plenty of NMEA phrases - too many. And opencpn been veeeeeeeeeeeeeeery slow now and barely reacting. The GPS repeater expects 3 sentences and nothing more 

  GSA for the fix of the satellites
  RMC for the SOG and bearing
  RMB for the waypoint distance, name, and track

And in a very specific form. I filtered the output to be sent at opencpn to the Arduino down to RMB, RMC and GSA. GSA does not exist in the menu of opencpn drop down filter, but you can add it manually. For me it is completely unclear, why the programmers have omitted that important sentence. Having applied this filter the terminal showed now mainly 

  GNGSA and
  GNRMC and
  GPRMC  (mark the difference in the second letter N to P

Once a waypoint was activated, GNRMB was also shown. And the GPS repeater still laughing („No GPS signal and No GPS SOG“)

Software - Postprocessing data from opencpn into readable GPS repeater data

Now I had to correct the data sent by opencpn into proper data for the GPS clipper. I did not do the often described parse and putting it back again, because this will slow down the Arduino. The issue is not to slow down the reading at the Arduino, else it may be overloaded to listen to new data coming in. So I had to make sure to process all changes very quickly within the loop.

  1. Reading loops - Reading of the data at USB:
    The data transfer from the PC to Arduino via the USB is asynchronous, meaning if there is data, the Arduino reads it, if not, it stays calm. It means the Arduino needs to wait until it has received the end of the line of the NMEA phrase sent or to stop, once a certain timeout has been reached. All reading buffers must be reset after a successful reading, else short phrases received will be amended by the old stuff from longer sentences. The famous “while (Serial.available()) “ loop does not work properly. In the beginning i tried it within that loop only and it drove me close to nuts. There are pauses in the sending, however the phrase was not yet completely sent over. As a result that string was too short and barely useful phrases were received. The solution is to let the Arduino run so long receiving the phrases until it has reached the * indicating it has now received a complete NMEA phrase. That manner the Arduino compiles a full senseful NMEA phrase after several reading loops.
  2. NMEA Sender ID
    The ID should be $GP and not $GN. The GPS device sends GN and opencpn transfers that through as GN. The GPS clipper currently does not care, what the pre-ID is (GN or GP or), but you never know for future releases of NMEA and hardware. So put it right and you won’t get into problems lateron. First step to convert all GNGSA into GPGSA. Same for RMC and RMB
  3. Different baudrates of connected units
    My GPS receiver (Kendau) sends with a baudrate of 9600 from its serial interface to the PC and opencpn. The connection at opencpn is configured to 9600. Since the NMEA output of opencpn to the Arduino is at half speed (=4800), we get 2 GSA phrases with completely different content. One good fix with many satellites and one lousy fix with nearly nothing. This causes hick-ups at the GPS repeater, which switches always between the 2 contents. The Arduino now has to delete these lousy GSA fixes, which do not contain at least 2 satellites or send only the good ones over to the GPS repeater.
  4. RMC phrase correction - There are 2 RMC phrases having different content:
    One with GNRMC and one with GPRMC. This is a an error at opencpn and to me unclear why happening. The 2 different RMCs yield a flickering at the GPS clipper’s display, because track and SOG differ. One is in the new NMEA 0183 format with time format ending in “.000”. The other one is elder with the time still formatted as 6 letter value. The one with “.000” is the correct one, as I found out. Check the picture for the RMC phrase.

Now important: !!

Both RMC phrases lack the value for magnetic variation and direction = East or West. When the GPS, plotter or plotter programs like opencpn don’t have it, they send a Null, meaning “,,,” in the string - three commas with nothing between them. But the GPS repeater needs them definitely. If not in the sentence sent to the clipper, the laughing continues („no GPS SOG“). The values for magnetic variation are achieved at opencpn by activating the WMM plugin. Unfortunately this tool is running out at the end of 2019, then we need to enter the data manually. For owners in Europe not a big issue, but for those with significant figures as in the Caribbean the figure is a must. I entered a manual figure of 1.2 going to E, since my boat is in Holland. You need to enter something applying for your area.

5) CRC Checksum of phrase sent
Unfortunately you cannot just replace the letters in the string containing GNGSA or add something in RMC, you need also to calculate the new CRC checksum. It is sent as 2 HEX digits after the * (star) to indicate the GPS repeater („hey, now the checksum comes”). The repeater itself checks the string from behind the „$“ till one before the „*“ with the checksum received. If equal, it processes the string, if not the data is discarded ( and „no GPS signal“)

6) Ending of NMEA phrase sent
The NMEA phrase sent to the GPS repeater must end with CRLN or „\r\n“ or 1310. This can be realized in the Arduino code with the various methods. No further „CRLN“ with nothing ahead of it (=empty lines) shall be sent to the GPS clipper, else it hicks up.

7) Finally the Arduino sends out three NMEA phrases, which the GPS clipper repeater understands and can process: 

  GPGSA with „P“ instead of „N“ and at least 2 satellites caught and new CRC
  GPRMC with „P“ instead of „N“ , magnetic variation, direction and new CRC
  GPRMB with „P“ instead of „N“ and new CRC.

The other sentences like XTE, APL,WPL etc. are ignored, since i use no autopilot

Hardware - Connecting the Arduino to GPS repeater

We can not use the standard pins at the Arduino for sending the data to the repeater. The USB interface at the Arduino uses standard pins (RX - pin 0, TX pin1) to read data from the PC. We can not use these pins hence the data would go back to the computer. We have to use another serial pin, what most Arduinos offer (not all). I used AltSoftSerial as serial setup library (do not use Softwareserial !) to allow for another serial port. Not every Arduino and every other pin can be used for AltSoftSerial, only dedicated pins. In my case pin 8 for RX and pin 9 for TX - for details and other boards check the board documentation of the library.

Finally I am able to send the corrected NMEA phrases through pin 9, but this is a TTL signal (between 0 and 5V), not a signal fulfilling the RS232 protocol needs by the GPS repeater. We connect a RS232 shifter to the pins (8,9), get the volts & ground from the Arduino.

I tried several “shifters” (= converter TTL to RS232) out and funnily not everyone works fine. Some corrupted the output. How did I find out ? Because I hooked up a further Arduino with its own RS 232 converter at the output of the first Arduino with its RS232 signal and read what the first one produced. This second Arduino only reads out and sends that to my terminal program at the PC. So I could check, what really goes out to the GPS repeater.

Now hooking up the Arduino physically to the GPS repeater:

  1. TX (send) wire from the RS232 shifter (converter) behind the Arduino to the blue wire of the GPS repeater
  2. Ground wire from the Arduino or RS232 shifter Ground to the shielding cable of the GPS repeater

Now we see at least some figures at the display, but still crumble in the jungle. We decipher funnily the NMEA sentences running through the display fields of the GPS repeater, but no data making any sense.

Now comes the secret of success:

RS 232 communication requires the sender to work at a load - what straight sending from the RS232 shifter does not. We have to wire a resistor between the TX cable of the RS232 shifter and its or Arduino’s ground to create that load. Which resiatance. Something between 1 and 10 kOhm. You need to check it out depending on your specific setup and eventual ore or less additional connected listeners. Once done, press the button for POSN at the GPS repeater, wait a little bit and you will shout out „Hurray“. The data is displayed in proper form.

Waypoint activation

We are not yet done. In my case out of a sudden the distance to waypoint and bearing to waypoint disappeared. One day it worked, another day not. Although the opencpn display showed all information, it did not appear on my GPS clipper. Responsible for that information is the RMB NMEA phrase, which did not show up in the NMEA debugger window. I reset at opencpn all connections, cleared the routes and did other senseless, non-logical pressing of buttons and flags at the opencpn. After some time it worked again. I have no clue why. I was even close to construct the RMB phrase out of other NMEA phrases like APL, WPL, but found out, they weren’t sent either. So although having activated the waypoint and been shown on the opencpn’s display, the relevant phrases were not sent out as proper NMEA phrases. Seems to me to be a bug in the software. Additionally the update frequency of the RMB phrase is very low and need more updateing. RMC and GSA are sent 5 times per second, RM only all 5-10 seconds. Makes to me no sense. Less frequency for RMC, GSA and and higher frequency for RMB (2 seconds at least).

Connection of Arduino to other NMEA listeners

Of course the sentences sent by the Arduino may be received also by others like autopilot or VHF or what else. Since I do not know what exactly these devices require, I can not tell much. If they request RS485, you need to add also a RS485/422 shifter at the pins 8/9 of the Arduino. The program will send the same data either as RS232 and RS485 to the devices. Do not mix these signals in one wire !! You will get number crunch salad on all devices. I do not know if the NMEA data sent from opencpn is good enough to fulfill the demands of autopilot or whatever, because I have none. I converted 2 years ago the piller of my boat to a wheel with hydraulic steering and would be prepared to add eventual also a hydraulic autopilot. Although I’d be interested to test it out, I dread the costs for an additional oil pump. If somebody is willing to sell me a used and functional electric oilpump with 30 cm³/revision (= 1 fl oz/revision) and 12 V DC at a very reasonable price (<100 $ incl. shipping) , I would start checking that out. Send a mail to kurt.orthmann@kuma97.de

Thanks